At the end of this chapter you will be able to:
Understand how WebLogic Server JMS is implemented Configure JMS administered objects using the administration console Configure persistent messages Use the WLS administration console to monitor JMS
Message-Oriented Middleware
Message-oriented middleware refers to an infrastructure that supports messaging.
Typical message-oriented middleware architectures define these elements:
Message structure
The way to send and receive messages
Scaling guidelines
Point-to-Point (PTP) Queue
Many producers can serialize messages to multiple receivers in a queue.
Publish-Subscribe Topics
Publishing and subscribing to a topic decouple producers from consumers.
WebLogic Server JMS Features
WebLogic Server JMS supports:
PTP and Pub/subdomains
Guaranteed and transactional message delivery
Durable subscribers
Distributed destinations
Recovery from failed servers
JMS Architecture: Connecting
JMS Architecture: Sending Messages
Transacted Messaging
A JMS client can use JTA to participate in a distributed transaction.
Alternatively, a JMS client can demarcate transactions local to the JMS Session, through a transacted session.
Participation in a transaction is optional.
Inclined to build a profession as Weblogic Developer? Then here is the blog post on, explore Weblogic Training
Administrative Tasks
Administrative tasks include these:
Creating and monitoring JMS Servers
Creating connection factories
Creating and monitoring destinations
Creating JMS stores
Configuring thresholds and quotas
Configuring durable subscriptions
Managing JMS service fail-over
WLS JMS Server
In WLS, the messaging service is implemented through a JMS Server.
A JMS Server receives and distributes messages.
Create a JMS Server
Target a JMS Server
Configure a JMS Server
JMS Resources
JMS resources are managed as system modules, application modules, or packaged JDBC resource modules.
Modular JMS Resource Configuration and Deployment...
JMS configurations in WebLogic Server are stored as modules
Defined by an XML file that conforms to the Weblogic-jmsmd.xsd schema
Similar to standard J2EE modules
An administrator can create and manage JMS modules as:
Global system resources
Global standalone modules
Modules packaged with an enterprise application
An advantage of modular deployment is simplified migration between environments, such as:
From development to integration
From system test to production
You can migrate your application and the required JMS configuration:
Without opening an EAR file
Without extensive manual JMS reconfiguration
Connection Factory
A connection factory:
Encapsulates connection configuration information
Is used to create pre-configured connections
Is stored in JNDI
Can be targeted to servers or clusters
WLS provides a default connection factory that is bound in JNDI to weblogic.jms.ConnectionFactory.
When a new configuration is required, a new connection factory can be created.
Configure Connection Factory: Default Delivery
Configure Connection Factory: Client
Configure Connection Factory: Transactions
Configure Connection Factory: Flow Control
Destination
A destination is a lightweight object stored in JNDI.
It is the target on a JMS Server for sending or receiving messages.
The JMS destination types are:
Create a Queue Destination…
Threshold and Quota
A threshold and a quota can be set for Server and Destination objects.
A quota is a limit defined for JMS administered objects; it includes these values:
The maximum number of bytes that can be stored
The maximum number of messages that can be stored
A threshold is a limit that triggers message paging, flow control, and logged warnings, using:
Upper and lower values for the number of bytes
Upper and lower values for the number of messages
Configuring Thresholds and Quotas
Configuring Persistent Messaging Durable Subscribers and Subscriptions
Durable subscribers register durable subscriptions to guarantee message delivery even if subscribers are inactive.
A subscriber is considered active if the Java object that represents it exists.
By default, subscribers are non-durable.
Administrators configure:
Where messages are persisted
Persistent connection factories and destinations
When to Use Persistent Messaging
Persistent messaging permits messages in memory to be written out to a persistent store.
Configure persistent messaging if:
Development requires durable subscriptions (use durable subscribers in the application)
You require that in-progress messages persist across server restarts
How a Durable Subscription Works
If a subscriber client is active, messages are delivered normally:
When the client becomes active again, its ID is used to retrieve and redeliver messages.
Configure a Durable Subscription
To configure durable subscriptions, an administrator must:
Create and configure a JMS store
Configure connection factories or destinations as persistent
Associate the JMS store with the JMS Server
The JMS store can be configured to use either:
A file store
A JDBC store (a connection pool)
Create a JMS File Store…
Create a JMS JDBC Store…
To configure JMS JDBC persistence:
Create a JDBC DataSource.
Create a JMS store and refer to the JDBC DataSource.
Refer to the JMS store from the JMS Server configuration.
The required infrastructure (tables, and so on) is created automatically.
Assign a Store to a JMS Server
Persistent Connection Factory
Monitoring JMS in WLS Statistics for JMS Objects
Statistics are provided for the following JMS objects:
JMS servers
Connections
Destinations
Monitor JMS Servers…
Monitor Destinations
Summary: In this chapter, we learned how to:
Understand messaging concepts Understand WebLogic Server’s JMS support Configure JMS servers, queues, and topics Monitor JMS servers, queues, and topics
Check out our Related Courses You liked the article?
Like: 0
Vote for difficulty
Current difficulty (Avg): Medium
Recommended Articles Page : 1 2 
